Aspects of the present invention relate to providing user interface language options, and more specifically, to providing language options for text of user interface elements.
Localization uses methods of transforming computer applications to different languages, regional differences and technical requirements of a target audience known as the locale. An application may be localized by adding locale-specific components and translating user visible text that is externalized into resource bundles that are separate to the computer application code module. The text in the resource bundle is translated into different languages for different regions or locales where the application is operated. Resource bundles of applications exist for each language. The application may load a locale-specific resource from the resource bundle that is appropriate for the locale. Application code may be written which is independent of the locale by isolating the locale-specific information in resource bundles. This allows the application code to be created and distributed independently of the resource bundles.
The text displayed by a user interface is the most obvious example of locale-specific data. For example, an application with a “Cancel” button in English speaking countries will have an “Abbrechen” button in German speaking countries. In other countries, this button will have other labels. This button label should not be hard-coded if the application is intended to be used in different countries. Isolating the locale-specific objects in a resource bundle enables different language options to be provided. In general, the objects stored in a resource bundle are predefined and ship with the product.
A user of software with a graphical user interface (GUI) may wish to use words contained within the GUI of an application, for example, to search the web for additional information. An example of this is when a message appears indicating a possible error and they want to see if others have encountered the same message and what their resolution was.
A problem occurs when a user wishes to use text from the software, such as an error message, to search the web but the user is running the software in a language different to the language that the web content is written in. The advantage of using the web, rather than the built-in documentation for the product, is that this will search forums, blogs, and other content that includes results and answers from the range of Internet users.
For example, the user may be running the software in German and may have an error message: “Verbindungsaufbau fehlgeschlagen mit Fehler ‘Moglicher SSL’”. The English version of the software has the corresponding error message: “Connect failed with error ‘Possible SSL connection failure’”.
When a user who uses the software in German wants to search the web for help with the error they might copy the error message into their clipboard, paste it into a search engine, and look for results. If the web content is in English, then the search for the German phrase finds no results.
The search for the English error message finds links to blogs and forums for how to solve the problem, posted by other users who have encountered the same problem and written how to resolve it.
One solution for the German user is to use an on-line translation. If this solution is used, then errors in translation may occur. For example the phrase: “Verbindungsaufbau fehlgeschlagen mit Fehler Moglicher ssl” may result in “Connectionless failed with error of possible ssl”. Searching on this inaccurate English translation does not yield the search results that the actual English error message does and the German user cannot find the right forum entries.
A solution that occurs is that users in countries where English is not the primary language run the software in English because this gives them the widest scope to reference on-line material, such as blogs, forums, wikis to guide them through the software usage. A typical scenario is that German users run their software in English, rather than German. This creates a need for the end user to be literate in English to be able to operate the software, restricting the skill and cost of the end user.
Another solution is to prefix all messages with a unique ID that is not translated, for example, an error message might have a prefix IZE0106E that a user can select and use as the search string for documentation and help. The disadvantage of this is that the string keys clutter the screen. They are also only shown in error messages and not descriptive strings so they are limited in where they are and where results can be found. In forum posts where end users are describing how to resolve a problem, the unique ID may not be included as the English discussion will be about the words of the message rather than the ID.